Introduces a MTLSMode field on AgentRuntimeSpec and plumbs it through
the existing CR > namespace > default resolution chain so the
admission webhook can render an mtls: block into the per-agent
authbridge ConfigMap. With this in place, kagenti-extensions PR rossoctl#424
(mTLS between authbridge sidecars on the proxy-sidecar / lite paths)
can be enabled declaratively per workload instead of by hand-editing
the namespace ConfigMap.

Behavior:

  * MTLSMode enum: disabled (default) | permissive | strict.
    Resolution: AgentRuntime CR > namespace authbridge-runtime-config
    mtls.mode > "disabled". Mirrors the existing AuthBridgeMode chain.

  * Per-agent ConfigMap renders top-level mtls: {mode: <value>} when
    resolved mode is non-disabled. Cert paths are intentionally not
    emitted — they default to authbridge's bundled-spiffe-helper
    convention (/opt/svid.pem, /opt/svid_key.pem, /opt/svid_bundle.pem),
    so surfacing them here would couple the operator to authbridge's
    internal layout for no benefit. Stale mtls blocks in the base YAML
    are scrubbed when toggling back to disabled.

  * mtlsMode != disabled implicitly requires SPIRE because the bundled
    spiffe-helper writes the X.509 SVID files mTLS reads. The pod
    mutator auto-enables SPIRE for the workload when mtlsMode is set
    — operators don't need to add the spiffe-helper-inject label
    separately. The operator does not mutate the namespace
    authbridge-config ConfigMap (which would race with the kagenti
    meta-chart for ownership); it just changes the in-memory
    injection decision.

  * The AgentRuntime validating webhook rejects mtlsMode != disabled
    when authBridgeMode is envoy-sidecar. Envoy SDS isn't currently
    configured by the kagenti envoy-config, so accepting the combo
    would silently produce a workload running plaintext on the wire
    while the user believed they had strict mTLS. The error message
    points to the supported modes (proxy-sidecar / lite) and flags
    this as a current limitation, not a permanent one — when the
    envoy-config gains SDS support, the rejection just goes away.

  * Spec changes to AuthBridgeMode and MTLSMode now flow into the
    AgentRuntime controller's resolved-config hash. Editing either
    field re-stamps the kagenti.io/config-hash pod-template annotation
    and the Deployment rolls automatically. (Pre-existing gap fixed
    along the way: AuthBridgeMode changes also weren't triggering
    rollouts before this commit.)

Out of scope:

  * envoy-sidecar mTLS via Envoy SDS — separate piece of work in the
    kagenti meta-chart's envoy-config template.

  * Namespace-level authbridge-runtime-config edits triggering
    rollouts. Today the namespace ConfigMap is consumed by the
    admission webhook only; namespace-level mtls.mode changes won't
    auto-roll existing workloads. Operators editing the namespace
    config should kubectl rollout restart manually until that's
    addressed.

  * Chart-side CRD at charts/kagenti-operator/crds/ is intentionally
    not touched. That copy has been drifting from
    config/crd/bases/ since commit 677f63d (predates `lite` mode
    entirely). Recent CRD-touching commits (4eb62af, 21a2258) follow
    the same "config is source of truth" pattern; this PR matches.
    Cleaning up the chart-side drift is a separate concern.

Tests added:

  * ExtractMTLSMode parser cases (empty, missing block, unknown mode,
    malformed YAML, mtls coexisting with other top-level blocks).

  * ensurePerAgentConfigMap: strict and permissive emit the block;
    disabled and "" omit the block; stale-block scrubbing on toggle
    back to disabled.

  * Validating webhook: 11-case matrix of (mode, mtls) combinations
    on Create and Update; envoy-sidecar + non-disabled rejected,
    error message points to the follow-up.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>

Two pre-existing tech-debt items folded into the mtlsMode wiring PR
(addressing reviewer-callout from PR rossoctl#369 itself):

1. Namespace-CM-edit rollout gap.

   The controller's resolved-config hash captured a few CR fields and
   the cluster-defaults / namespace-defaults ConfigMaps, but NOT the
   namespace authbridge-runtime-config ConfigMap that the admission
   webhook reads at pod creation. So `kubectl edit configmap
   authbridge-runtime-config -n team1` silently failed to roll the
   workloads in that namespace — operators had to know to run
   `kubectl rollout restart` manually.

   - Add an AuthBridgeRuntime field to resolvedConfig that captures
     the raw config.yaml content (not parsed — any byte change rolls
     the workload, agnostic to whether it's mtls / pipeline / listener
     edits).
   - Extend mapNamespaceConfigMapToAgentRuntimes to also match
     ConfigMaps named "authbridge-runtime-config" (not just
     kagenti.io/defaults=true labeled ones), so edits to that CM
     enqueue every AgentRuntime in the namespace and the hash
     re-stamps the pod template.
   - New constant AuthBridgeRuntimeConfigMapName for the magic name.
     Other places in the codebase still use the literal string;
     consolidating them is out of scope.
   - Tests: hash-changes-on-edit (extends ComputeConfigHash spec) +
     mapper-matches-by-name (extends the existing namespace mapper
     test).

2. Chart-CRD drift.

   charts/kagenti-operator/crds/ holds a manually-maintained Helm
   crds/ directory copy of the AgentRuntime + AgentCard CRDs. It was
   last touched in commit 677f63d (initial webhook migration) and
   has been silently drifting from kagenti-operator/config/crd/bases/
   for at least three subsequent CRD-touching commits (21a2258, 4eb62af,
   and earlier this PR). Anyone helm-installing got an outdated CRD
   missing recent fields like authBridgeMode / lite mode / mtlsMode.

   - Sync both CRDs from config/crd/bases/ to charts/.../crds/.
   - Add a sync-chart-crds Makefile target invoked at the tail of
     `make manifests`, so future controller-gen regenerations
     propagate to the chart copy automatically. Skips the stub
     `_.yaml` controller-gen sometimes emits.

PR rossoctl#369 originally noted both items as out-of-scope follow-ups; this
commit folds them in per reviewer/maintainer feedback.

Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Hai Huang <huang195@gmail.com>